home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CD ROM Paradise Collection 4
/
CD ROM Paradise Collection 4 1995 Nov.iso
/
bbs
/
jdrexa10.zip
/
INST4OF4.DAT
/
BBS
/
GIP_02.ZIP
/
GIP-SPEC.DOC
< prev
next >
Wrap
Text File
|
1994-12-18
|
38KB
|
835 lines
Graphic Interchange Protocol (GIP) Technical Standards -- Request For Comment
Document #2 release .02
New stuff since .01 has a "│" as the first character of the line.
The GIP specifications: the developer's viewpoint.
OVERVIEW
Most of this document is dedicated to the actual protocol used between
the host and the terminal. However, there are 4 other major programming
tasks involved: processing text/file for GIP codes, processing the input
stream for GIP codes, actually doing the graphics, and working with
objects.
GIP.ASM is included to make the graphics part easy, and it should be used.
The parsing jobs depend a lot on how you design your program, and/or how
it normally handles I/O. GIP is just like ANSI and Avatar, just add a few
extra code hooks to your I/O. Objects are a bit more confusing because
they are kinda convoluted. Check out my code in ViewGIP, Commie, and
Juggernaut for quicky answers.
The protocol is only half the implementation of GIP. Right now, at least,
the other half is being able to do the graphics in the same manner I do.
Example: the protocol defines a box and provides two coordinates, but you
must also put that box at the proper coordinates (use 0 to N - 1, not 1 to
N, for example). The easiest way to test for this compatibility is using
the .GIP sample files included here, or those from the Juggernaut files.
COMMANDS
h and v are coordinates. These go from 0 to N - 1 (N depends on the
graphics mode). 0,0 is the upper-left corner of the screen. The
numbers are integers (0, 1, 2, 3, etc.) "h" are the cordinates along
the line (horizontal coordinates), and "v" are the vertical (up/down)
coordinates.
d is the depth for 3-D, and isn't coded for yet.
The h,v,d values may either represent actual screen coordinates, or
offsets from the last-used coordinate, command dependent. When they are
offset values, negative numbers can be used. A "0" offset value means to
draw at least one pixel--since you are drawing from the current pixel to
pixel location + 0.
n is a number, and its values are also command dependent.
Within each command is text for developers. This contains the actual
exchange specification information. A program that is to send GIP
standard codes must convert the input stream to this format and send it.
A program that is to receive GIP standard codes must convert the input
stream from this to the various GIP actions.
Also as part of the developers information section is what EACH SIDE is
expected to do. For the most part, both the sending and receiving side
do all things listed.
The GIP codes (such as "S2;") are not sent (exchanged) between the BBS
and comm program in the form which they are read in. The main difference
being that the numbers are converted. So that instead of sending "123" as
"1", "2", "3", we convert it to an integer and send the two-byte integer
instead. This offers a slight throughput advantage, but also makes the
code writing on the comm program's end much easier.
Sending side: when you do things is up to you. Example: you can change
to the color before sending the "Cn;" code, or after sending it.
Notation: <x> when "x" is an ASCII number in byte (8 bit) form.
[x] when "x" is a REAL number in integer (16 bit) form.
{x} when "x" is something more complex.
[[x]] when "x" is LONG number (32 bit).
Variables you will need to maintain: color, pattern, currentH, currentV,
currentD, objects, patternshift
Examples:
"Sn;" is exchanged as "<19><83><byte>" where "<byte>" contains
the value of "n".
"Mh,v,d;" is exchanged as "<19><77><int><int><int>" where the three
"<int>"'s contain the values of "h", "v", and "d" in that
order.
Notice that the "" (ASCII 19) and the "S" and "M" are sent. Then the
numbers are converted and sent. The comma's and semi-colons are not
sent. The numbers are NOT sent as a series of ASCII characters, but
converted to byte or 2-byte integer form and then sent as a byte or
two bytes. The case of the "S" or "M" is significant.
NOTE: For now, "d" is always 0.
For the most part error checking need not be done (for example: if a box
command orders a box outside valid range). Although DOS does handle these
pretty well, the fact is that an MNP modem for error correction is pretty
necessary when using this, and that if a sysop designs a menu that will fail
then they need to correct it to have users using it.
If the specs look like there is lots of oportunity for failure, that's
because that's the way it was designed. Selected for speed rather than
reliability. The logic: most people have MNP modems, and most sysops won't
design GIP menus/text that cause their users to get stuck with a bad GIP
code. This philosophy is continued in the lack of any way for a user to
abort a GIP command in the middle (except through modem time-out). But if
people really do have problems, or there is a need, I will re-write the
specs to allow for more error-handling (although, frankly, the error
handling would look very much like MNP which is why I didn't do it now).
COMMAND DESCRIPTION
Sn; Switch to graphics mode n.
Where n is: 0 for standard 80x25 mode.
1 for 320x200x4 CGA (testing mode only).
2 for 640x480x16 VGA.
3 for 320x200x256 VGA.
4 for 640x480x256 SVGA.
5 for 800x600x256 SVGA.
Example: S2;
Begins graphic mode 2.
S0;
Returns back to normal (ANSI) mode.
Modes 4 and 5 require an SVGA card, and are a bit less-automatic
for beginner users. For general-audience graphics, you should
stick with modes 2 and 3.
Mode 2 provides for 80x60x16 text. While Mode 4 only provides
for 40x25x256 text.
For normal operations, mode 2 is the only real practical mode.
It's drawback is that some sysops might find it's text a little
small. This will be solved for in the future when I add support
for more fonts.
│ When this command is used, the current h,v,d positional values
│ should be reset to 0. Thus, it can be interpreted as a standard
│ clear-screen and go-to-top-of-screen order. Like ANSI's "[2J" or
│ DOS's CLS. Similarly, you should set the color to Bright White
│ (C15). Finally, the pattern should be reset to a solid line.
│ GIP (ASCII 19) commands should be ignored unless already in
│ graphics mode. So an Sn; command will precede all.
BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM
│
Obtain "Sn;". │
│
IF n > 255 then don't process. │
│
Send "<19><83><n>". │ Receive "<19><83><n>".
│
If the bbs/host system can │ If the system can handle the
handle the screen mode, then │ screen mode, then change to
change to that mode. │ that mode.
│
Reset your line-pattern │ Reset your line-pattern
variable to solid (-1 or 65534). │ variable to solid (-1 or 65534).
Reset your pattern shift │ Reset your pattern shift
variable to 0. │ variable to 0.
EXAMPLE: "S2;" is sent (and received) as "<19><83><2>"
(3 bytes).
NOTE: We just change the line-pattern variable here, because there
is nothing to draw/display. The drawing commands should have
a parameter for line-pattern-to-use.
If the mode cannot be handled, then use 0--it's safer then
trying to squeeze higher resolution graphics into lower
modes.
Cn; Switch to color n.
Where n is: 0 to 15
0 to 255
Example: C0;
Change the current color to black.
This depends on what mode you are in (either 16 or 256 colors).
The 16 color mode follows the same color scheme as ANSI does.
BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM
│
Obtain "Cn;". │
│
IF n > 255 then don't process. │
│
Send "<19><67><n>". │ Receive "<19><67><n>".
│
Set your color variable to this │ Set your color variable to this
value. │ value.
EXAMPLE: "C64;" is sent (and received) as "<19><83><64>"
(3 bytes).
NOTE: DOS properly handles out-of-range values (eg. 16-255 in a
16 color mode) by "wrapping" to the first color and starting
again the counter.
We just change a variable here, because there is nothing to
draw/display. The drawing commands should have a parameter
for pixel color to use.
Pn,s; Set the "pattern" to use for drawing lines and filling boxes.
Where n is: 0 to 65534
-1 to 32767
A 16 character pattern of 0's and 1's (example:
0000111100001111).
Where s is: -15 to 15
Example: P1,0;
or
P0000000000000001,0;
will use " ∙" (15 blanks and then a
dot) for the pattern for drawing lines, boxes, etc.
The pattern is the same as formed by the ON/OFF bits of the
number n, with an ON bit being a visible pixel, and an OFF
bit being a skipped pixel.
An exception is zero, this is changed to "-1" or "65534" and is
equivalent to a solid line of pixels. I did this to make it
easier to work with, and because "all pixels off" lines aren't
likely to be needed.
The default is a solid line, and this default is selected each
time you change the screen mode. Otherwise the pattern defined
stays in effect until you do a new pattern-change or another
screen mode change.
At the start of each line drawing order, we begin with the left-
most pixel, and continue on through to the right. Starting again
at the left after the 16th pixel.
The exception to this is filled boxes. In order to avoid
streaking lines, we incorpate "s"--the shift value. After each
line when drawing a filled box, the bit pattern will be shifted
according to s. A negative value means to rotate left, a
positive value means to rotate right, a zero means no shifting.
For example, for the "on-off-on-off" pattern, no shifting would
yield not a pattern, but an organized set of vertical lines. If
you shift more than one, you get organized slanted lines. So the
shift you use depends on that pattern you use, and will probably
require a little trial and error.
BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM
│
Obtain "Pn,s;". │
│
If n = 0 then set n = -1. │
│
Send "<19><80>[n][s]". │ Receive "<19><80>[n][s]".
│
│ If n = 0 then set n = -1.
│
Set your pattern variable to │ Set your pattern variable to
this n value. │ this n value.
Set your shiftingvariable to │ Set your shifting variable to
this s value. │ this s value.
EXAMPLE: "P64,-1;" is sent (and received) as "<19><80>[64][-1]"
(6 bytes).
NOTE: We just change a variable here, because there is nothing to
draw/display. The drawing commands should have a parameter
for pattern to use.
In a bit of "reverse logic" if the value of n is 0, you
should use instead -1 or 65534--that is, a filled pattern
for solid lines. The reasoning: a blank pattern won't be
needed, so lets not confuse ourselves with -1 or 65534 and
just use "P0,0;" to reset to solid lines.
The pattern shifting value only needs to be used when
drawing filled boxes--you do a bitshift in the specified
direction after drawing each line.
Gh,v,d; Go to point h,v,d.
Example: G10,10,0;
will move to graphics location 10,10.
Nothing is displayed.
h,v,d cannot be negative numbers.
This is the most used command, as it's used to place lines,
boxes, and text.
BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM
│
Obtain "Gh,v,d;". │
│
IF h, v, or d, is < 0 then don't │
process. │
│
Send "<19><71>[h][v][d]". │ Receive "<19><71>[h][v][d]".
│
Set your internal location-at │ Set your internal location-at
variables to these three values. │ variables to these three values.
EXAMPLE: "G100,200,0;" is sent (and received) as
"<19><71>[100][200][0]" (8 bytes).
NOTE: We just change variables here, because there is nothing to
draw/display. The drawing commands should have parameters
for h,v,d coordinates to start at.
Mh,v,d; Go to offset point h,v,d.
Example: G20,20,0;
will move from the current location to offset 20,20.
After the call, the new current location is 10,10 +
the h,v offset (30,30).
Nothing is displayed.
This command is usually only used when defining objects, which
by their nature can't be screen coordinate dependant.
BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM
│
Obtain "Mh,v,d;". │
│
Send "<19><77>[h][v][d]". │ Receive "<19><77>[h][v][d]".
│
Set your internal location-at │ Set your internal location-at
variables by adding these values │ variables by adding these values
to them. │ to them.
EXAMPLE: "M100,-50,0;" is sent (and received) as
"<19><77>[100][-50][0]" (8 bytes).
NOTE: We just change variables here, because there is nothing to
draw/display. The drawing commands should have parameters
for h,v,d coordinates to start at.
Lh,v,d; Draw a line from current point to h,v,d.
Example: L20,20,0;
will draw a line, in the current color, from the
current location to offset 20,20. After the call,
the new current location is 10,10 + the h,v offset.
There is no "draw a point" command. To draw points, use very
short lines.
BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM
│
Obtain "Lh,v,d;". │
│
Send "<19><76>[h][v][d]". │ Receive "<19><76>[h][v][d]".
│
Set your internal location-at │ Set your internal location-at
variables by adding these values │ variables by adding these values
to them. │ to them.
│
Draw a line from your old │ Draw a line from your old
location-at variables to your │ location-at variables to your
new location-at variables using │ new location-at variables using
your color variable and your │ your color variable and your
pattern variable. │ pattern variable.
EXAMPLE: "L100,-50,0;" is sent (and received) as
"<19><76>[100][-50][0]" (8 bytes).
Bh,v,d; Draw a rectangle from the current postition to h,v,d. Where
h,v,d is the opposite corner of the rectangle.
Example: B20,20,0;
will draw a line-box, in the current color, from the
current location to offset 20,20. After the call
│ the current location is still 20,20,0.
The current pattern is also used--since the box is usually
drawn as four lines.
BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM
│
Obtain "Bh,v,d;". │
│
Send "<19><66>[h][v][d]". │ Receive "<19><66>[h][v][d]".
│
│ Draw a box from your current │ Draw a box from your current
│ location-at variables to │ location-at variables to
│ location-at + these values using │ location-at + these values using
│ your color variable and your │ your color variable and your
│ pattern variable. │ pattern variable.
EXAMPLE: "B100,-50,0;" is sent (and received) as
"<19><66>[100][-50][0]" (8 bytes).
Fh,v,d; Draw a filled/solid rectangle from the current postition to
corner h,v,d. Where h,v,d is the opposite corner of the rectangle.
Example: F20,20,0;
will draw a filled box, in the current color, from the
current location to offset 20,20. After the call,
│ the current location is still 20,20,0.
The current pattern is also used.
If you're trying to draw a box over text, and you get "ghosting"
of the previous stuff in that area--that's a sure sign that you
forgot to reset your pattern to solid--that "ghosting" is pixels
being skipped due to the pattern.
There is no hard rules on how to program for this. I use a hack
of just drawing lines to form the box, and after each line
rotating the bitmask of the pattern left 1 bit. This provides
me with more of a dither look rather than the horizontal lines
this method would usually generate.
BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM
│
Obtain "Fh,v,d;". │
│
Send "<19><70>[h][v][d]". │ Receive "<19><70>[h][v][d]".
│
│ Draw a solid box from your │ Draw a solid box from your
│ current location-at variables to │ current location-at variables to
│ location-at + these values using │ location-at + these values using
│ your color variable and your │ your color variable and your
│ pattern variable. │ pattern variable.
EXAMPLE: "F100,-50,0;" is sent (and received) as
"<19><70>[100][-50][0]" (8 bytes).
fPATHNAME;
The file exchange protocol. The heart of GIP. It is used to
send any files. Including .GIF's, .ICO's, .MOD's, .VOC's, etc.
The software determines what to do with your file based on the
file's extension. So if it's a GIF, use .GIF display, etc.
Example: fC:\BBS\NCD.ICO;
would display C:\BBS\NCD.ICO with it's upper-left
corner starting at the current location.
fC:\BBS\METAL.VOC;
would play C:\BBS\METAL.VOC.
It's really an "update protocol"--since the file will not be
sent if the current version of the file already exists on the
callers disk in his "your BBS identifier" directory.
The path is not sent, only the filename.
The current coordinates are not changed.
In general, it works as such:
Send Header with CRC.
ACK receipt of header.
If file is new/updated, then ENQ for a new file, else ACK that
we already have it and it shouldn't be re-sent.
BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM
│
Obtain "fpathname;". │
│
IF pathname not found, then │
don't process. │
│
Send "<19><102>" │ Receive "<19><102>".
│
Create variable x to contain: │
8 bytes, the GIP ID. │
12 bytes, the filename in │
"file.ext " form. │
4 byte LONG, the file's size. │
2 byte INTEGER, the file's │
time. │
2 byte INTEGER, the file's │
date. │
│
Then we calculate a 16 bit CRC │
(xmodem/etc. standard) of x, call│
it c. │
│
Example: for "TESTER.ZIP 1,100,959 10:00:00 5/1/93",
and the BBS's GIP ID is "STARCH",
we send:
"STARCH TESTER.ZIP [[size]][time][date]"
1. Send "{x}[c]" │ Receive "{x}[c]"
│
Loop until receive "<5>" or │ If c is not the CRC of x,
"<6>". │ then send "<5>" and goto 1.
│
If receive "<5>" then goto 1. │
│
│ Send "<6>" and goto 2.
│
If receive "<6>" then goto 2. │
│
NOTE: I designed my code to give up and exit after 5 tries or if
the console had <esc> hit. Each try occuring if time-out
or "resend" (ASCII 5) received. Time-out can be your
choosing, 2-5 seconds probably best, but I use the fossil's
own 30 second time-out.
2. Loop until receive "<5>" or │ Compare the file's name, date,
"<6>". │ and size with what's on-line
│ in directory "GIP ID".
│
│ If match, send "<6>" goto 3.
If receive "<6>" then goto 3. │
│ Send "<5>".
│
Send "{x}" where x is the │ Receive the file's contents
contents of the file. Only the │ into the specified filename in
mere beginnings of a protocol │ the "GIP ID" directory. We
here: We send 1024 byte blocks │ receive the file's size's worth
followed by a delay in which we │ of bytes. This is done by
wait for the other guy to send │ receiving 1024 bytes, writing
a character. The final block │ it to a file, and then sending
can be less than 1024 bytes. │ back a "<6>", and repeating.
│
│ Give the file the time and date
│ that we passed earlier.
NOTE: Example: a file of size 2050 bytes:
Sender: Receiver:
send first 1024 bytes
receive first 1024 bytes
send "<6>"
receive "<6>"
send second 1024 bytes
receive second 1024 bytes
send "<6>"
receive "<6>"
send last 2 bytes
receive last 2 bytes
send "<6>"
receive "<6>"
The 1024 and waiting for ACK is done so we don't overflow
│ buffers and lose characters. [might drop this in the
│ future as unnecessary]
3. Display the file. │ Display the file.
NOTE: "Display the file." for now merely means:
"If extension is .ICO, then call up show icon routine and
display this icon file." These are "standard" 766 byte
sized 16-color icon files.
Thus, for now only .ICO files are supported. More graphic
formats will be added in the future.
Any other format should be displayed as a normal text/ansi
file of any size.
Except for .BMP--the trouble is that right now the only
BMP displayer I has displays the colors slightly off.
On;~xxx~ Define an object for later display.
Where n is: 0 to 255
Example: O1;~C3;G5,5,0;L15,5,0;L15,15,0;L5,15,0;L5,5,0;~
Which defines Object #1 to be orders to: change to
color 3 and goto 5,5 and draw a box.
It's very flexible, you can have GIP codes and normal text
intermixed.
It's not displayed at the time you define/send it.
Only three restrictions: no GIP "f<pathname>" commands nor other
object commands (either defining or using) should be inside the
two "~" characters. And, of course, no "~" allowed inside the
definition.
This is the cyberspace command, with which we will have
cyberspace in the future.
When defining objects, the maximum size of any one object is
2048 bytes, and the size of all objects must not exceed 8192
bytes. If you need to exceed these limits, I recommend using
either an icon or graphic image file.
BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM
│
Obtain "On;~xxx~". │
│
IF n > 255 then don't process. │
│
Store "xxx" in objects-variable │
number n. │
│
Send "<19><79>[n][z]xxx". │ Receive "<19><79>[n][z]".
Where z is the length of "xxx". │
│ IF n > 255 then don't process.
│
│ Receive "xxx" for length z.
│
│ Store "xxx" in objects-variable
│ number n.
EXAMPLE: "O64;~hi there~" is sent (and received) as
"<19><79>[64][8]hi there" (14 bytes).
NOTE: Nothing is shown/displayed.
If there are GIP codes in the "xxx" then these are not
converted to anything (just yet). Thus "C2;HiC3;there"
stays in this form when stored to the object variable.
on; Call up and display/use an Object.
Where n is: 0 to 255
Example: o1;
Will display Object #1 we defined earlier.
This offers fast graphics, since the commands do not have to
be re-sent each time you want to display the same thing.
It also offers the sysop convience. When testing postioning
of GIP drawings, and when working with lots of the same
drawings.
BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM
│
Obtain "on;". │
│
IF n > 255 then don't process. │
│
Send "<19><111><n>". │ Receive "<19><111><n>".
│
│ IF n > 255 then don't process.
│
Process the data stored in │ Process the data stored in
object n's variable. │ object n's variable.
For GIP codes, we convert and │ For GIP codes, we need a minor
process as normal, but don't │ BBS-like parser to convert them
send them out the port. │ to usable form.
EXAMPLE: "o2;" is sent (and received) as "<19><111><2>"
(3 bytes).
NOTE: Processing GIP codes from Terminal side is not as hard as
it may first seem (see example source code).
ASCII TEXT
Text is like lines--its pixels are drawn on top of whatever is there
already. It uses whatever was the last defined color, at whatever was
the last location.
For now, only an 8x8 font is used. After each character is displayed,
we automatically add 8 to the orginal (pre-drawing) horizontal location,
which has the effect of putting us right where the next character would
be drawn.
For spans of spaces, 8 or fewer spaces is more efficient than using a
"Gh,v,d;" command to move you ahead.
For CR/LF's, we simply change the horizontal coordinate to zero, and add
8 to the vertical coordinate. This allows us to display normal text going
down the screen normally. However, there are problems when you reach the
end of the screen--as the there no scrolling in GIP (nor any wraparound to
the next lines). Think of CR/LF's this way: just another cursor positioning
command: "go to start of next line".
Usually the effects of CR/LF's do not matter. They are very useful for
making GIP files readable. So don't be afraid to use them for that purpose.
The full 256 character ASCII set may be sent and displayed except for the
following codes: 10, 13, 19, 12, 22, 25, 27
These codes are used by ANSI, GIP, Avatar, and text to signify something
besides their normal ASCII character.
EXAMPLES
"S2;fC:\BBS\NODE001\GRA\PIC1.ICO;G300,300,0;Hi there!"
will: clear the screen and go to graphics mode (S2;)
send the file PIC1.ICO (if the caller doesn't have it already)
(fC:\BBS\NODE001\GRA\PIC1.ICO;)
locate pixel 300,300 (G300,300,0;)
and display "Hi there!" at that point (normal ASCII text)
"S2;G300,300,0;fC:\BBS\NODE001\GRA\PIC1.ICO;Hi there!"
will: same as the above, but draws the icon at 300,300 and "Hi there!"
right after the icon.
NOTES
GIP codes, like ANSI, can be put into files and displayed. I recommend
the extension .GIP (like .ANS) but it's not required.
GIP contains no error-checking stuff, and so should only be used by MNP
modems (the baud doesn't matter).
Before shelling to dos (or exiting the program) you should reset the
graphics mode to normal 80x25 ANSI.
CONVERTING TEXT FILES TO GIP
For bare bones conversion of a standard text file to gip, there are only
two things to do:
Add a "Sn;Cn;" at the start of the file.
Add a "S0;" at the end of the file.
CONVERTING ANSI FILES TO GIP
These are the steps to follow that to make conversi of ANSI's easier:
First, convert the "[xC" "cursor jumping" commands to their spaces
equivalent. Example "[7C" becomes " ". You can optimize it with
"Gh,v,d;" commands later. A "Gh,v,d;" command uses 8 characters in it's
transmission, so there is nothing to be gained by reducing gaps 8 or fewer
characters to "Gh,v,d;" calls.
Second, convert the "[x,y,zm" color commands. Easy except for background
commands "[44m"--in which case you'll probably want to first draw a filled
box of the length desired and then draw the characters on top of it.
The above stuff on converting normal text files is useful too.
0,8,16,24 etc. correspond to normal 80x25 text columns.
VIEWGIP
Also enclosed is VIEWGIP.EXE.
ViewGIP will let you display files with GIP codes inside them. It works
much like TYPE filename.ANS works. Just type: VIEWGIP filename.GIP
The only limitations are that the two SVGA modes won't work with this
viewer, and the maximum file size is 16k.
The program will display the file, and then wait for you to hit a key.
For best viewing, I recommend you remove any "S0;" mode-to-normal you
have at the end of the file before displaying.
The source code for ViewGIP is VIEWGIP.BAS. Like all the included
source code, it both uses the GIP.ASM graphic routines, and makes use
of some of my assembly routines from Juggernaut (not included).
COMMIE
Commie is available in a separate archive. Your users can use this
program to see your GIP graphics.
The source code to Commie is COMMIE.BAS. For those interested in
adding GIP ability to their communications program, this will be
invaluable. For those interested in adding it to BBS programs, you
should get the Juggernaut program and take a look at it.
CONCLUSION
All of the above stuff is already coded and done. The only supported file
│ display format right now is ".ICO" for icons, and .BMP for images--and I'm
│ looking for source code to display ANY other graphic formats.
The stuff below still needs to be done, and will be available sometime in
the future:
d coordinates (depth/3-D stuff)
GIFs/TIFs/PCXs/BMPs
sound files (VOC/MOD)
fonts (TrueType preferred)
circle's/elipses
etc.
This is a very open-ended standard. It's success and power depend on other
people supplying code for many of the things not done. For instance, I
don't know 3-D graphics programming, the drivers for sound cards, or how to
display the various image file formats. I'll teach myself and get it, but
reinventing wheels is not efficient. So feel free to help.
I can be reached for comment/suggestions at:
Immortality
414-643-1576
24 hrs.
Either log in, or just dump your NetMail on me.
John Rohner
January 1994
I hereby release the GIP specifications, and any code specific only to
implementing the GIP specifications I include as an example, to the Public
Domain for full, free, and uncredited distribution by other GIP-capable
program authors.
With the premediated hope that authors will simply import the code into their
program to provide GIP support. With a promise to never challenge nor
discredit said authors, and that this Public Domain declaration shall be
eternal.
This declaration does not extend to the various subroutines used to form the
example programs in which the GIP subroutines reside.